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A COMMUNICATION NETWORK 

PRE-APPEAL BRIEF REQUEST FOR REVIEW 

MAIL STOP AT - PATENTS 

Commissioner for Patents 
P.O. Box 1450 
Alexandria, VA 22313-1450 

Sir: 

Pursuant to the Pre-Appeal Brief Conference Pilot Program, and further to the Examiner's Final 
Office Action dated October 7, 2008, Applicant files this Pre-Appeal Brief Request for Review. This 
Request is also accompanied by the filing of a Notice of Appeal. 

Applicant turns now to the rejections at issue: Claim 1 recites "processing means for receiving, 
from an equipment in a communications network, primary data defining events in at least one primary 
format and delivering to a management device in said network secondary data defining alarms 
representing said events, in a secondary format." 

The Examiner cited Larson at paragraph [0129], lines 4-8, as allegedly teaching primary data 
defining events, as recited in claim 1 . In addition, the Examiner cited Larson at paragraph [-129], lines 9- 
16 ads allegedly teaching secondary data defining alarms, as recited in claim 1 . See page 3 of the Final 
Office Action of October 7, 2008. 

Specifically, the Examiner alleges that a "problematic device (equipment) generates SNMP traps 
(primary data defining event in primary format) and [an] NMS system [which] receives it." See page 3 of 
the Final Office Action of October 7, 2008. In other words, the Examiner seems to interpret the SNMP 
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traps in Larson as corresponding to the primary data defining events according to claim 1 . In addition, the 
Examiner seems to allege that the Network management System (NMS) in Larson corresponds to the 
processing means according to claim 1 . 

Finally, the Examiner contends that the XML file in Larson, which is generated by the NMS 
system, corresponds to secondary data defining alarms, as recited in claim 1. See page 3 of the Office 
Action. In summary, the Examiner contends that the SNMP traps and XML files in Larson correspond to 
events and alarms , respectively, in claim 1 . 

Based on the above, the Examiner further contends that Larson teaches "wherein said processing 
means comprise an interpreter which is provided with a plurality of conversion rules, arranged in the form 
of scripts that are interpreted by the interpreter and are associated with a plurality of different primary 
event formats, and arranged so as to convert, by means of said rules, primary data received in one of said 
primary formats into secondary data in said secondary format which can be processed by said 
management device," as recited in claim 1 . Applicants respectfully disagree with the Examiner's 
interpretation of the Larson reference. 

First, a person of ordinary skill in the art would not have interpreted the XML file in Larson as 
corresponding to secondary data defining alarms in the meaning of claim 1 . Instead, a person of ordinary 
skill in the art would have interpreted alerts {see FIG. 6, step 96), and not the XML file, as corresponding 
to secondary data defining alarms, as recited in claim 1 . That is, because Larson teaches "[djepending on 
the event, the NMS will ignore it, log it, or generate an alert." See paragraph [0129], lines 8-9. 

Second, even assuming, arguendo, that one would have interpreted the XML file as secondary 
data defining alarms, Larson clearly does not disclose or suggest "a plurality of conversion rules . . . 
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arranged so as to convert, by means of said rules, primary data received . . . into secondary data," as 
recited in claim 1. 

The Examiner contends that Larson teaches this unique feature of claim 1, citing paragraph 
[0129], lines 9-16, and alleging that the "NMS system runs scripts to convert SNMP traps to XML 
messages." See page 3 of the Final Office Action of October 7, 2008. However, as FIG. 6 of Larson 
clearly shows, the " Alert " (element 96), and not the " Event " (element 92) is converted into an XML file 
by using a script (step 98). In other words, the script in Larson is used to convert alerts, which represent a 
format that is different to the event format, into a third format, namely the XML file format. In addition, 
before these alerts are converted in Larson, the NMS system might ignore certain events which makes it 
simply impossible to convert such ignored events by using the script. That is, why in Larson the alerts, 
and not the events, are converted into XML files which is clearly different from converting "primary data 
received in one . . . primary format . . . into secondary data in . . . secondary format," as recited in claim 1 . 

Finally, even assuming for the sake of argument that one would interpret Larson as teaching an 
indirect conversion of events into XML files via alerts, Larson does not disclose or suggest "a plurality of 
conversion rules . . . associated with a plurality of different primary event formats . . . [and] each of the 
plurality of different primary event formats corresponds to a particular script," as recited in claim 1 . 

The Examiner concedes that Larson does not disclose or suggest the above-noted unique feature 
of claim 1 . However, the Examiner contends that Weiss cures the deficiencies of Larson. See pages 3 
and 4 of the Final Office Action of October 7, 2008. 

In the January 30, 2009, Response, Applicants submitted that if one would substitute the single 
script of Larson, which generates XML RFC based on SNMP traps (see Larson at paragraph [0129]) with 
the plurality of scripts in Weiss, which are [each] associated with exactly one event, such a combination 
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would still not disclose or suggest a plurality of conversion rules arranged in particular scripts and 
corresponding to a plurality of different primary events, as recited in claim 1. See page 4 of the January 
30 Response. 

In response, the Examiner alleges that "the combination of Larson and Weiss would yield a 
system with a plurality of different event formats (Larson may only disclose one event format, but the 
addition of more formats would not change the principle operation of Larson, i.e., converting network 
events and the examiner sees no reason how the addition of more event formats would preclude Larson 
from converting SMTP traps as it already does), and respective scripts for said formats." See page 2 of 
the Advisory Action of February 25, 2009. 

Weiss teaches events, such as for example "Internet telephony connection attempt, receipt of an 
Internet instant messaging request, or the receipt of an e-mail message from a particular sender." In 
addition, these events trigger corresponding alarms. See paragraph [0094]. A particular script which 
contains only one "line executing an alarm script" is used to alert the user. See paragraph [0094]. In 
other words, Weiss does not teach any conversion of event formats into secondary formats. Instead, the 
script is used to "play ... a particular sound file," for example. See paragraph [0095]. 

The above-noted examples of events do not represent different event formats in the meaning of 
claim 1 . Even assuming, arguendo, that a person of ordinary skill in the art would have interpreted the 
above discussed examples of events in Weiss as different event formats, replacing the script of Larson 
with the plurality of scripts of Weiss would not lead to a plurality of different primary event formats 
which corresponds to a particular script. That is, because each of the alleged formats in Weiss would only 
define one event since it contains only one command line. However, claim 1 requires primary data 
defining events (plural) in at least one primary format, i.e., more that one event per event format. 
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As a result, Larson in view of Weiss does not disclose or suggest all of the elements as set forth 
and arranged in claim 1. Therefore, Applicants submit that claim 1 would not have been obvious under 
35 U.S.C. § 103(a) over Larson in view of Weiss. Independent claims 14, 15 and 28 recite analogous 
features as claim 1 and are patentable for analogous reasons as claim 1. 

Stilwell does not remedy the deficiencies of Larson in view of Weiss. Claims 2, 10-13, 16-27, 29 
and 3 1-34 depend from claims 1,15 and 28, respectively, and are patentable at least by virtue of their 
dependencies. 

Respectfully submitted, 

/Kelly G. Hvndman 39.234/ 
SUGHRUE MION, PLLC Kelly G. Hyndman 

Telephone: (202)293-7060 Registration No. 39,234 

Facsimile: (202)293-7860 

WASHINGTON OFFICE 

23373 

CUSTOMER NUMBER 

Date: March 9, 2009 
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